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DETAILED ACTION 

Response to Remarks 

1 . This Office action is considered fully responsive to the amendment filed 5/4/09. 

2. The objections to claims 1 , 5, and 17 have been withdrawn because they have 
been amended accordingly. 

3. The rejections of claims 3,12,1 6-1 7 under U.S.C. 1 1 2 have been withdrawn 
because the claims have been amended accordingly. Additionally, the Examiner 
concurs with the Applicant about the rejection of claim 6, hence the rejection under 
U.S.C. 112 has been withdrawn. 

Response to Arguments 

1 . Applicant's arguments with respect to claim 1-4 have been considered but are 
moot in view of the new ground(s) of rejection. 

2. Applicant's arguments regarding claims 5-17 filed 5/4/09 have been fully 
considered but they are not persuasive. Note that the grounds of rejection for claims 1- 
4 change due to the "user profile configured by an operator" in independent claim 1 , 
however the same art is kept for the other limitations of independent claim 1 , which also 
relates to independent claim 5, which are clarified below. 

Applicant presents various arguments to allegedly prove that the Riedel 
reference is for use on a user terminal device, in contrary to claim 1 (and similarly claim 
5) with arguments stating it is "well known" that the RACS is a network device (page 10, 
Remarks). The Examiner disagrees that it is "well known" that the RACS is a network 
device and even if one were to assert that is "well known" that the RACS is a network 
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device, a user terminal device as in Riedel still reads on this as a user terminal device is 
part of a network and hence is a network device. 

Even more, in response to applicant's argument that the references fail to show 
certain features of applicant's invention, it is noted that the features upon which 
applicant relies (i.e., "the RACS can get the availability of the resources on the whole 
network instead of the availability of the resources on a certain node" (page 10, 
Remarks)) are not recited in the rejected claim(s). Although the claims are interpreted 
in light of the specification, limitations from the specification are not read into the claims. 
See In re Van Geuns, 988 F.2d 1 181 , 26 USPQ2d 1057 (Fed. Cir. 1993). 

Further, In response to applicant's argument that "the solution of the instant 
application and the technical effect thereof are different from those of Riedel (page 1 1 , 
Remarks)", a recitation of the intended use of the claimed invention must result in a 
structural difference between the claimed invention and the prior art in order to 
patentably distinguish the claimed invention from the prior art. If the prior art structure is 
capable of performing the intended use, then it meets the claim. 

Applicant further alleges that Riedel does not teach "an RACS.... for execution" 
and "the Transport Functional entity" (page 1 1 , Remarks). However, the crux of the 
Applicants arguments did not involve disproving any of the Examiner's rejections of the 
claim limitations, rather it focused on alleging that Riedel refers to a user device 
whereas the claim refers to a network device. The Examiner points to the rejection 
below to the specific limitations and how Riedel teaches those limitations. As was 
mentioned in the previous Office action, Riedel does not expressly disclose the 
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transport functional entity, adapted to ensure QoS of the media flow of the service 
transferred in NGN according to the admission control decision parameters. Ruutu was 
used to teach these missing limitations. Again, the Exaimer provides a citation from 
para. 0043 and fig. 5, which states "networks employing QoS may transmit messages 
subject to QoS parameters.", and this clearly teaches the missing limitations. Ruutu 
temporarily storing a message as stated by the Applicant (page 1 1 , Remarks) has 
nothing to do with the missing limitation and does not detract at all from the citation 
given by the Examiner. 

Lastly, the Applicant argues that there is no motivation to combine Riedel and 
Ruutu (page 12, Remarks). However, the Examiner provided clear motivation in the 
previous Office action: The suggestion/motivation would have been to provide end-to- 
end quality of service for application message transfers utilizing message queues 
(Ruutu, para. 0001). 

Claim Objections 

3. Claim 1 is objected to because of the following informalities: "and user profile" 
should be "and a user profile". Appropriate correction is required. 



Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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5. Claims 1-2, 4 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
U.S. Publication No. 2003/01 12766 A1 to Riedel etal. {"Riedef) in view of U.S. 
Publication No. 2004/0151114 A1 to Ruutu and in further view of U.S. Publication No. 
2007/0005368 A1 to Chutorash etal. ("Chutorash"). 

As to claim 1, Riedel discloses a system of dynamic QoS negotiation in Next 
Generation Network (NGN) (para. 0001 , dynamic QoS management), comprising: a 
Resource and Admission Control Subsystem (RACS), adapted to obtain and process a 
resource reservation request required for a media flow of a service transferred in NGN 
(abstract, fig. 3, QoS management unit 304 processes QoS request messages), 
perform authentication (para. 0008, QoS application requirements include 
authentication, para. 0037, control information for managing reservation flow state done 
in IP packet, i.e. IP packets authenticated by use of checksum) and determine 
admission control decision parameters based on operation policy rules, and user profile, 
and availability of transport network resources (fig. 3, table 1, QoS reporting unit 320 
generates report based on input signals from handover management unit 314 and QoS 
monitoring unit 318, which monitors current QoS situation (i.e. availability and rules), 
(also para. 0036, availability of QoS path, QoS dynamically set/changed pertaining to 
rules) and 314c provides information about expected QoS parameters after handover 
(i.e. expected pertaining to what a user requests, meaning their particular profile for that 
session, para. 0036 also discussing adaptive applications supported w/ actual feedback 
of QoS dependent network information, i.e. their particular user status determines how 
they perform along the QoS path based on the parameters given), and send the 
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admission control decision parameters to a concerned Transport Functional (TF) entity 
for execution (table 1 , report is transferred to QoS application interface unit 324), 
wherein said reservation request contains QoS requirement parameters (abstract, fig. 3, 
QoS management unit processes QoS request messages). 

Riedel does not expressly disclose user profile configured by an operator, the 
Transport Functional entity, adapted to ensure QoS of the media flow of the service 
transferred in NGN according to the admission control decision parameters. 

Ruutu discloses in para. 0043, fig. 5, networks employing QoS may transmit 
messages subject to QoS parameters. 

Riedel and Ruutu are analogous art because they are from the same field of 
endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the transmission according to QoS parameters as taught by 
Ruutu into the invention of Riedel. The suggestion/motivation would have been to 
provide end-to-end quality of service for application message transfers utilizing 
message queues (Ruutu, para. 0001). 

Chutorash discloses the occupant can establish preferences for the behavior ( 
user profile) of system 10 (para. 0029), i.e. user profiled configured by occupant. 

Riedel, Ruutu, and Chutorash are analogous art because they are from the same 
field of endeavor with regards to data processing. 
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At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the occupant establishing preferences of user profile as taught 
by Chutorash into the invention of Riedel and Ruutu. The suggestion/motivation would 
have been to operate a speech recognition system in a vehicle (Chutorash, para. 0006). 

As to claim 2, Riedel, Ruutu, and Chutorash further disclose the system as in 
claim 1, wherein the system further comprises: a service control functional (SCF) entity, 
adapted to obtain the QoS requirement parameters required for the service requested 
by a user terminal by parsing service signaling or determine the QoS requirement 
parameters according to the service policies, and send the QoS requirement 
parameters to said RACS (Riedel, table 1 , fig. 3, QoS reporting unit 320 obtains QoS 
parameters based on several factors (also take 320 as SCF), and this information is 
transferred to QoS application interface unit 324 (which is within RACS, hence it is sent 
to RACS), Ruutu, fig. 5, para. 0043-0044, input messages w/ QoS parameters obtained 
by queuing module 504 (i.e. SCF), and the parameters are sent to output buffer (i.e. 
RACS, which allocates resources based on QoS)). In addition, the 
suggestion/motivation of claim 1 applies. 

As to claim 4, Riedel, Ruutu, and Chutorash further disclose the system as in 
claim 1, wherein the RACS obtains the QoS requirement parameter information from 
the TF entity (Riedel, table 1 , fig. 3, QoS application interface unit 324 is within QoS 
Management unit 304, hence this information is obtained by 304). In addition, the 
suggestion/motivation of claim 1 applies. 
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6. Claim 3 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedeletal. {"RiedeP'), U.S. Publication No. 
2004/0151 1 14 A1 to Ruutu, and U.S. Publication No. 2007/0005368 A1 to Chutorash et 
al. ("Chutorash") and in further view of U.S. 2004/0131042 A1 to Lillie et al. ("Lillie"). 

As to claim 3, Riedel, Ruutu, and Chutorash further disclose the system as in 
claim 2, wherein the system further comprises: a Network Attachment Subsystem 
(NASS), adapted to manage and configure user access network (Riedel, fig. 3, table 1 , 
QoS Network Interface Unit 326), communicate with said RACS and said SCF entity 
(Riedel, fig. 3, table 1 , 326 part of 304, and take SCF to be 306 which is also part of 
304), 
1. 

Riedel, Ruutu, and Chutorash do not expressly disclose and provide said RACS 
and said SCF entity with user profile information associated with the service. 

Lillie discloses registration manager 202 maintains information describing media 
capabilities of each endpoint and a user profile. Furthermore, these capabilities are 
sent as an extension to the standard REGISTER requests, also the group database 
manager 208 of each successful registration or re-registration request that it processes 
is notified, (para. 0061 , i.e. notify RACS management and SCF entity of user profile 
information). 

Riedel, Ruutu, Chutorash and Lillie are analogous art because they are from the 
same field of endeavor with regards to data processing. 
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At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the user profile information forwarded as taught by Lillie into the 
invention of Riedel, Ruutu, and Chutorash. The suggestion/motivation would have been 
to enable a group directed session between at least two endpoints in a communications 
system (Lillie, para. 0006). 

2. Claims 5-7, 12-13 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over U.S. Publication No. 2003/01 12766 A1 to Riedel et al. {"Riedef') in view of U.S. 
Publication No. 2004/0151114 A1 to Ruutu. 

As to claim 5, Riedel discloses a method of dynamic QoS negotiation based on 
the system of dynamic QoS negotiation in Next Generation Network (NGN) (para. 0001, 
dynamic QoS management), comprising: 

A. obtaining, by a Resource and Admission Control Subsystem (RACS) in NGN, 
QoS requirement parameters required by a service (abstract, fig. 3, table 1 , QoS 
management unit 304 processes QoS request messages, parameters are provided); 

B. performing, by said RACS, admission control in accordance with the QoS 
requirement parameters, and determining admission control decision parameters (fig. 3, 
table 1 , QoS reporting unit 320 generates report based on input signals from handover 
management unit 314 and QoS monitoring unit 318, which monitors current QoS 
situation (i.e. availability and rules), (also para. 0036, availability of QoS path, QoS 
dynamically set/changed pertaining to rules) and 314c provides information about 
expected QoS parameters after handover (i.e. expected pertaining to what a user 
requests, meaning their particular profile for that session, para. 0036 also discussing 
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adaptive applications supported w/ actual feedback of QoS dependent network 
information, i.e. their particular user status determines how they perform along the QoS 
path based on the parameters given); 

C. sending, by said RACS, the admission control decision parameters to a 
transport functional (TF) entity at network boundary (table 1 , report is transferred to QoS 
application interface unit 324) 

Riedel does not expressly disclose and executing, by said transport functional 
entity at network boundary, the admission control decision parameters to process and 
transfer the media flow of the service accordingly. 

Ruutu discloses in para. 0043, fig. 5, networks employing QoS may transmit 
messages subject to QoS parameters. 

Riedel and Ruutu are analogous art because they are from the same field of 
endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the transmission according to QoS parameters as taught by 
Ruutu into the invention of Riedel. The suggestion/motivation would have been to 
provide end-to-end quality of service for application message transfers utilizing 
message queues (Ruutu, para. 0001). 

As to claim 6, Riedel and Ruutu further disclose the system as in claim 1 , 
obtaining, by said RACS, the QoS requirement parameters of the service through a 
Service Control Functional (SCF) entity, a Network Attachment Subsystem (NASS), the 
TF entity, or a Network Management System (NMS) (Riedel, table 1 , fig. 3, QoS 
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application interface unit 324 is within QoS Management unit 304, hence this 
information is obtained by 304). In addition, the suggestion/motivation of claim 1 
applies. 

As to claim 7, Riedel and Ruutu further disclose the method as in claim 5, 
wherein when the service comprises a plurality of media flows, it is needed to determine 
the QoS requirement parameters for each of the media flows respectively (Ruutu, fig. 5, 
para. 0043-0044, various messages from various applications with QoS, the messages 
are prioritized). In addition, the same suggestion/motivation of claim 5 applies. 

As to claim 12, Riedel and Ruutu further disclose the method as in claim 5, 
wherein said determining by the RACS the admission control decision parameters 
comprises: obtaining, by the RACS, user profile information of the service and policy 
rules information configured by an operator (fig. 3, table 1 , QoS reporting unit 320 
generates report based on input signals from handover management unit 314 and QoS 
monitoring unit 318, which monitors current QoS situation (i.e. availability and rules), 
(also para. 0036, availability of QoS path, QoS dynamically set/changed pertaining to 
rules, i.e. configured by dynamic applications) and 314c provides information about 
expected QoS parameters after handover (i.e. expected pertaining to what a user 
requests, meaning their particular profile for that session, para. 0036 also discussing 
adaptive applications supported w/ actual feedback of QoS dependent network 
information, i.e. their particular user status determines how they perform along the QoS 
path based on the parameters given), making admission control decision for the QoS 
requirement parameters of the service based on the user profile information and the 
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policy rules information (Riedel, abstract, table 1, fig. 3, preallocation, soft/hard 
handovers managed by QoS management unit 304, based on QoS parameters of 
users), deciding whether to permit the media flow of the service to enter into the 
transport network and to be treated with the requested QoS (Riedel, abstract, table 1 , 
fig. 3, preallocation, soft/hard handovers managed by QoS management unit 304, 
based on QoS parameters of users, i.e. bandwidth allocated), and determining the 
admission control decision parameters (Riedel, abstract, table 1, fig. 3, QoS report 
generated based on handover/monitoring results). In addition, the same 
suggestion/motivation of claim 5 applies. 

As to claim 13, Riedel and Ruutu further disclose the method as in claim 5, 
wherein determining by said RACS the admission control decision parameters 
comprises: obtaining, by the RACS, the current status information of the transport 
resources in the network (Riedel, abstract, table 1, fig. 3, QoS bandwidth information 
monitored by QoS management unit 304), making admission control decision for the 
QoS requirement parameters of the service based on above information (Riedel, 
abstract, table 1, fig. 3, preallocation, soft/hard handovers managed by QoS 
management unit 304, based on QoS parameters of users), checking whether there are 
enough transport resources available in the network to meet the QoS requirement 
parameters of the service (Riedel, abstract, table 1, fig. 3, preallocation, soft/hard 
handovers managed by QoS management unit 304, based on QoS parameters of 
users, i.e. bandwidth allocated), and determining the admission control decision 
parameters (Riedel, abstract, table 1, fig. 3, QoS report generated based on 
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handover/monitoring results). In addition, the same suggestion/motivation of claim 5 
applies. 

3. Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedeletal. ("Rieder) and U.S. Publication No. 
2004/0151 1 14 A1 to Ruutu and in further view of U.S. Publication No. 2003/0129988 A1 
to Lee et al. ("Lee"). 

As to claim 8, Riedel and Ruutu further disclose the method as in claim 6, 
wherein, before the step of obtaining by a Resource and Admission Control Subsystem 
(RACS) in NGN QoS requirement parameters required by a service the method further 
comprising a step E: 

initiating, by a user terminal, a service request to the SCF entity (Riedel, table 1 , 
abstract, fig. 3, nodes request QoS, goes to QoS management unit 304 (take to be SCF 
entity)); 

when the service request carries the QoS requirement parameters of the service, 
obtaining by the SCF entity the QoS requirement parameters of the service by parsing 
the service request (Riedel, table 1 , abstract, fig. 3, QoS requests sent to QoS 
management unit 304, fig. 5, note IP packet which contains this QoS information, i.e. 
packet is parsed). 

Riedel and Ruutu do not expressly disclose when the service request does not 
carry the QoS requirement parameters of the service, determining by the SCF entity the 
type of the service in accordance with the service request, and determining the QoS 
requirement parameters required for the service in accordance with the service type. 
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Lee discloses if the BSC 20 performs steps 102 and 104 as in the conventional 
technology, it determines whether the call requires the QoS service by checking 
whether a QoS parameter is included in a Call-Establishment-Req message. If the QoS 
parameter is not included (i.e. no QoS requirement parameters carried), the BSC 20 
requests the profile of a user for which the call is to be set up to the profile server 40 
and acquires it. The BSC 20 then determines whether a required QoS parameter can be 
provided by checking the received user profile in the format of FIG. 8A or 8B. If the 
service is available, that is, the user profile includes the QoS parameter, the BSC 
controller 31 1 goes to step 512 (i.e. determining service type, QoS parameter) (para. 
0073). 

Riedel, Ruutu, and Lee are analogous art because they are from the same field 
of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the determining service and QoS parameter as taught by Lee 
into the invention of Riedel and Ruutu. The suggestion/motivation would have been to 
determine the service and QoS parameter if they are not provided (Lee, para. 0073). 

4. Claim 9 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedel etal. {"Riedef'), U.S. Publication No. 
2004/0151 1 14 A1 to Ruutu and U.S. Publication No. 2003/0129988 A1 to Lee et al. 
("Lee") and in further view of U.S. Publication No. 2004/0022191 A1 to Bernet et al. 
("Bernet"). 
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As to claim 9, Riedel, Ruutu, and Lee do not expressly disclose the method as in 
claim 8, wherein when the user terminal is a fixed terminal, the step E further 
comprises: the SCF entity sending a resource reservation request containing the QoS 
requirement parameters of the service to the RACS via a corresponding interface with 
the RACS. 

Bernet discloses RSVP better suited for QoS data exchange between fixed 
endpoints (para. 0009). Furthermore, fig. 6 shows RSVP request going from sender S 
(take to be SCF) to Nn1 (take to be interface with RACS) to N2 (take to be RACS), and 
these nodes are fixed, not mobile. 

Riedel, Ruutu, Lee and Bernet are analogous art because they are from the 
same field of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the RSVP as taught by Bernet into the invention of Riedel, 
Ruutu and Lee. The suggestion/motivation would have been to allow RSVP signaling to 
be identified as qualitative (Bernet, para. 0011). 

5. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedel etal. ("R/ectef), U.S. Publication No. 
2004/0151 1 14 A1 to Ruutu, and U.S. Publication No. 2003/0129988 A1 to Lee et al. 
("Lee") and in further view of U.S. Publication No. 2001/0026554 A1 to Holler et al. 
("Holler"). 
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As to claim 10, Riedel, Ruutu, and Lee further disclose the method as in claim 8, 
wherein when the user terminal is a mobile terminal (Riedel, abstract, adaptive QoS for 
mobile devices), the step E further comprises: 

initiating, by the user terminal, a resource reservation request to the TF entity of 
the network via a path-coupling QoS signaling carrying the QoS requirement 
parameters of the service (Riedel, abstract, fig. 3, table 1, QoS requests (i.e. pertaining 
to BW allocation), go to QoS management unit 304, and in particular end up at QoS 
application interface unit 324 (take to be TF entity), which contains QoS parameters); 

handling by the TF entity at network boundary the QoS signaling (Riedel, 
abstract, fig. 3, table 1 , QoS application interface unit 324 (take to be TF entity) gives a 
report). 

Riedel, Ruutu, and Lee do not expressly disclose sending, by the SCF entity, a 
resource authentication request containing the QoS requirement parameters of the 
service to the RACS via a corresponding interface with the RACS; 

after authenticating successfully, notifying, by the RACS, the user terminal via 
the SCF entity; 

and sending a resource reservation request containing the QoS requirement 
parameters of the service to the RACS via a corresponding interface with the RACS. 

Holler discloses in fig. 8, para. 0098-0100, nodes involved in QoS requests, and 
RSVP. In particular, a gatekeeper 609 requests QoS from RSVP proxy in node 603 
(SCF requests to RACS via interface). Furthermore, after the request, RACS (603) 
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authenticates and sends a Path message to user 607 via SCF 609. Additionally, a 
RSVP resv message is sent to RACS 603 via interface w/ RACS 607. 

Riedel, Ruutu, Lee, and Holler are analogous art because they are from the 
same field of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the various reservation messages as taught by Holler into the 
invention of Riedel, Ruutu, and Lee. The suggestion/motivation would have been to 
have resource reservation for establishing end-to-end QoS (Holler, para. 0001). 

6. Claim 11 is rejected under 35 U.S. C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedel etal. ("R/'ede/"), U.S. Publication No. 
2004/0151 1 14 A1 to Ruutu, U.S. Publication No. 2003/0129988 A1 to Lee et al. ("Lee") 
and U.S. Publication No. 2001/0026554 A1 to Holler etal. ("Holler") and in further view 
of U.S. Publication No. 2004/0022191 A1 to Bemet et al. ("Bernet"). 

As to claim 1 1 , Riedel, Ruutu, Lee, and Holler further disclose sending, by the 
SCF entity, a resource authentication request containing the QoS requirement 
parameters of the service to the RACS via a corresponding interface with the RACS; 
after authenticating successfully, notifying, by the RACS, the user terminal via the SCF 
entity; initiating, by the user terminal, a resource reservation request to the TF entity of 
the network via a path-coupling QoS signaling carrying the QoS requirement 
parameters of the service; handling by the TF entity at network boundary the QoS 
signaling and sending a resource reservation request containing the QoS requirement 
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parameters of the service to the RACS via a corresponding interface with the RACS 
(see rejection for claim 10). 

Riedel, Ruutu, Lee, and Holler do not expressly disclose wherein when a token 
mechanism is used, the method further comprises: after authenticating successfully, 
returning by the RACS an admission token to the user terminal via the SCF entity; 
carrying the admission token in a path-coupling QoS signaling and transferring the 
admission token to the RACS via a resource reservation request; checking by the 
RACS whether the resource reservation request has passed the authentication and 
searching for relevant information of the service in accordance with the admission 
token. 

Bernet discloses Standard RSVP messages typically carry a quantitative 
description of the relevant QoS traffic in parameters referred to as token-bucket 
parameters (in Intserv semantics) (para. 0009), i.e. the QoS RSVP messages 
exchanged contain the admission token as token bucket parameters, and hence are 
used in QoS negotiations. 

Riedel, Ruutu, Lee, Holler, and Bernet are analogous art because they are from 
the same field of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the token bucker parameters as taught by Bernet into the 
invention of Riedel, Ruutu, Lee, and Holler. The suggestion/motivation would have 
been to provide a system and method that enables QoS to be based on qualitative 
factors (Bernet, para. 0011). 
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7. Claims 14, 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
U.S. Publication No. 2003/0112766 A1 to Riedeletal. {"Riedef) and U.S. Publication 
No. 2004/0151114 A1 to Ruutu and in further view of U.S. Publication No. 
2004/0228363 A1 to Adamczyk et al. ("Adamczyk"). 

As to claim 14, Riedel and Ruutu further disclose the method as in claim 5, 
wherein the admission control decision parameters comprise: 

bandwidth allocation, Differentiated Service Code Point mark, and outgoing 
aggregation path control information (Riedel, table 1, hard reservation 316b includes 
bandwidth availability, preallocation unit 314a declares QoS capabilities though a 
segment of a path, i.e. a path pertaining to aggregation of data over this path, fig. 5, 500 
showing DSCP). 

Riedel and Ruutu do not expressly disclose gate control. 

Adamczyk discloses a routing gate to control communications with a user (para. 

0583). 

Riedel, Ruutu, and Adamczyk are analogous art because they are from the same 
field of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the routing gate as taught by Adamczyk into the invention of 
Riedel and Ruutu. The suggestion/motivation would have been to control 
communications with a user (Adamczyk, para. 0583). 
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As to claim 17, Riedel and Ruutu further disclose the method as in claim 5, 
further comprising: 

configuring, by a Network Management System (NMS) or a Network Attachment 
Subsystem (NASS), bandwidth allocation, Differentiated Service Code Point (DSCP) 
marking control, and outgoing aggregation path control parameters onto the TF entity at 
network boundary via the RACS (Riedel, table 1, hard reservation 316b includes 
bandwidth availability, preallocation unit 314a declares QoS capabilities though a 
segment of a path, i.e. a path pertaining to aggregation of data over this path, 
parameters go to QoS application interface unit 324 at boundary of QoS manager, 
parameters configured in report form by QoS reporting unit 320, fig. 5, 500 showing 
DSCP). 

Riedel and Ruutu do not expressly disclose gate control. 

Adamczyk discloses a routing gate to control communications with a user (para. 
0583) and DiffServ Code Points (para. 0524). 

Riedel, Ruutu, and Adamczyk are analogous art because they are from the same 
field of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the routing gate as taught by Adamczyk into the invention of 
Riedel and Ruutu. The suggestion/motivation would have been to control 
communications with a user (Adamczyk, para. 0583). 

8. Claim 15 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedel etal. {"Riedef) and U.S. Publication No. 
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2004/01 51 1 1 4 A1 to Ruutu and in further view of U.S. Publication No. 2002/01 361 62 A1 
to Yoshimura et al. ("Yoshimura"). 

As to claim 15, Riedel and Ruutu further disclose the method as in claim 5, 
wherein the QoS requirement parameters comprise: bandwidth required for transporting 
the media flow of the service (Riedel, table 1 , soft reservation unit 31 6a, QoS 
capabilities e.g. certain amount of bandwidth, is defined), and where QoS for the 
provided communication service characterized by the bandwidth of different media 
stream and the delay, delay jitter and packet loss rate provided by the network (Riedel, 
para. 0005). 

Riedel and Ruutu do not expressly disclose wherein the QoS requirement 
parameters comprise allowable delay, jitter, and packet loss rate. 

Yoshimura discloses the RTCP report contains parameters such as the packet 
loss rate, the delay jitter (para. 0062). 

Riedel, Ruutu, and Yoshimura are analogous art because they are from the 
same field of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the parameters as taught by Yoshimura into the invention of 
Riedel and Ruutu. The suggestion/motivation would have been to classify the RTCP 
report according to these parameters and store them (Yoshimura, para. 0062). 

9. Claim 16 is rejected under 35 U.S.C. 103(a) as being unpatentable over U.S. 
Publication No. 2003/0112766 A1 to Riedel etal. {"Riedet') and U.S. Publication No. 
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2004/0151114 A1 toRuutuand in further view of U.S. Publication No. 2001/0026554 A1 
to Holler et al. ("Holler"). 

As to claim 16, Riedel and Ruutu further disclose directly initiating, by a user 
terminal, a resource reservation request to the TF entity for the media flow of the 
developed service via a dedicated path-coupling QoS signaling (Riedel, abstract, table 
1 , figs. 3-4, items 402a/b, 404, Ruutu, fig. 5, para. 0043-0044), and executing step C 
(see claim 5 rejection for step C); 

Riedel and Ruutu do not expressly disclose upon receiving the resource 
reservation request from a user terminal, sending, by the TF entity at network boundary, 
a resource reservation request carrying the QoS requirement parameters of the media 
flow of the user service to the RACS. 

Holler discloses in fig. 8, nodes involved in QoS requests, and RSVP. In 
particular, a RSVP Path signal is sent from 603 (take to be user) to 607 then to 608 
(take to be TF at the boundary), and then a RSVP Resv signal is sent from 608 to 607 
(take to be RACS) then to 603. 

Riedel, Ruutu, and Holler are analogous art because they are from the same field 
of endeavor with regards to data processing. 

At the time of invention, it would have been obvious to a person of ordinary skill 
in the art to incorporate the various reservation messages as taught by Holler into the 
invention of Riedel and Ruutu. The suggestion/motivation would have been to have 
resource reservation for establishing end-to-end QoS (Holler, para. 0001). 
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Conclusion 

10. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to OMAR GHOWRWAL whose telephone number is 
(571)270-5691 . The examiner can normally be reached on Monday-Thursday, 8:00am- 
5:00pm est.. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Derrick Ferris can be reached on (571)272-3123. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/O. G7 

Examiner, Art Unit 2416 
/Derrick W Ferris/ 

Supervisory Patent Examiner, Art Unit 2416 



